Skip to content

[FEATURE] Add permission sets to be_users#13

Open
calien666 wants to merge 1 commit intob13:mainfrom
calien666:feature/allow-user-permission-sets
Open

[FEATURE] Add permission sets to be_users#13
calien666 wants to merge 1 commit intob13:mainfrom
calien666:feature/allow-user-permission-sets

Conversation

@calien666
Copy link
Copy Markdown
Contributor

Having all groups deployable could be a big effort for large multisite systems. This will help manage large systems avoiding big changes in database if changes were made.

Having all groups deployable could be a big effort for large multisite
systems. This will help manage large systems avoiding big changes in
database if changes were made.
@achimfritz
Copy link
Copy Markdown
Contributor

Hi @calien666 , thanks for PR, can you explain the use case? (i don't see it)

@calien666
Copy link
Copy Markdown
Contributor Author

Hi @achimfritz,

Had to check, what I've done here. As far as I understood, there is no possibility making a fine granulated permission set per user. With permissions set for user, there would be the possibility skipping a database record for the group and directly access the set to the user, which has big advantages in multi domain instances and managing all permissions only per set and not inside the database. This makes the be_groups partially obsolete and avoids a huge list of backend groups in the database.

At the moment wer'e hosting a system, which has a pre-defined set of access permissions, which needs an adjustment for at least 11 groups per website inside the backend, having 4 of them directly accessed to backend users. With at least over 350 Websites multiplied by four groups, this leads us to about 1500 database groups needed for adding group permissions to the backend users. Having the possibility of a direct access to the permission sets inside the backend user instead of the group will decrease database groups massively and help us maintain sets with versioning.

@achimfritz
Copy link
Copy Markdown
Contributor

I think this is not the (our?) common way, and this change should not go into this extension

@saitho
Copy link
Copy Markdown

saitho commented Jun 4, 2025

With at least over 350 Websites multiplied by four groups, this leads us to about 1500 database groups needed for adding group permissions to the backend users. Having the possibility of a direct access to the permission sets inside the backend user instead of the group will decrease database groups massively and help us maintain sets with versioning.

350 websites in one installation sounds a lot to me. Does that work well? Back in TYPO3 7-ish we split a large installation into separate ones because of performance issues.

Back to topic: I understand this reduces backend groups, but is it really easier to update the users instead? To me, ensuring that group permissions are correct seems easier to do and validate. Applying them directly to the user sounds like people may easily forget some settings when creating new users.

@calien666
Copy link
Copy Markdown
Contributor Author

@saitho We don't have any issues in speed or performance. I maintained even bigger systems with up to 1200 domains inside one TYPO3 without any issues. The bigger system only used a Varnish Cache in front of the TYPO3 with Apache2 webserver.

Our 350 domain system currently only uses caching mechanisms from nginx and TYPO3, but most related cache is not stored inside the MariaDB, which causes issues, if you do so. Instead we use redis caching for pages and contents and smaller parts are directly served by the Solr search server (especially the event listing).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants